Remarks 

Claims 1-15, 17-22, 24, 25 and 27-34 are pending in the application. Claims 1-15, 
17-22, 24, 25, and 27-34 stand rejected. Claim 8 is amended. No new subject matter is 
added. Claims 1-15, 17-22, 24, 25 and 27-34 are now pending in the application 
Reconsideration and allowance of the pending claims is requested in light of the above 
amendments and the following remarks. 

Claim Rejections under 35 U.S.C. 103 

Claims 1-12, 13-14, 17, 20, 24-25 and 30-34 stand rejected under 35 U.S.C. § 103(a) 
as being unpatentable over Shenoy, et al. (U.S. Publication No. 2003/0223425 Al) in view of 
Yavatkar, et al. (U.S. Publication No. 2003/0128668 Al) and further in view of Moberg, et 
al. (U.S. Patent No. 6,697,872). The applicant traverses the rejections. 

Regarding claim 1, the claim recites "the line card is configured to filter mal-formed, 
illegal and duplicate update messages fi-om gateway peers." The Office Action 
acknowledges that this feature is not taught in Shenoy or Yavatkar, but then proposes that this 
feature is taught in Moberg at col. 4, lines 43-67 {see Office Action, page 1 1). The applicant 
respectfully disagrees. The cited portion of Moberg simply states that a line card processor 
can examine a packet to verify its validity. Moberg does not provide any further explanation 
of how the validity of a packet is determined, and specifically Moberg does not teach that 
such validity is based on mal-formed, illegal, or duplicate update messages. Further, the cited 
portion of Moberg specifically refers to the processing of data packets; not update messages 
from gateway peers. Consequently, Moberg does not teach this feature of claim 1 and thus 
does not remedy this deficiency of Shenoy and Yavatkar. Therefore, claim 1 is allowable 
over the combination of Shenoy, Yavatkar, and Moberg and allowance is respectfully 
requested. Dependent claims 2-7 are likewise allowable. 

Further regarding claim 7, the claim recites "the backplane further comprising a 
network." The Office Action acknowledges that Shenoy does not teach this feature, but then 
proposes that Yavatkar teaches this feature at backplane 26 (see Office Action, page 9). The 
applicant respectfully disagrees. The backplane 26 of Yavatkar is a physical backplane in a 
single router (see Yavatkar, FIG. 2 and paragraphs [0014-0019]). Yavatkar does not teach 
that the backplane 26 is a network or even that the line cards and control card can be located 
remotely from each other. Consequently, Yavatkar does not teach this feature and does not 
remedy this deficiency of Shenoy. 
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For at least this additional reason, claim 7 is allowable over the combination of Shenoy, 
Yavatkar, and Moberg and allowance is respectfully requested. 

Regarding claim 8, the claim is amended to clarify that the line card announces routes 
to the peer gateways. Shenoy does not teach this feature because Shenoy states that 
"forwarding information is generated by the processors. . .and managed centrally at the 
primary control module" {see Shenoy, paragraph [0022]). Shenoy goes on to describe how 
instances of this forwarding information are provided to the line cards by the primary control 
module {see id). Thus, this portion of Shenoy actually teaches that forwarding information is 
generated at either the control card or line cards, but that such information is only sent to the 
line cards from the control card; not from a line card to another router. Therefore, Shenoy 
does not teach this feature of the claim, which specifically refers to a line card announcing 
routes to peer gateways. Consequently, claim 8 is allowable over the combination of Shenoy, 
Yavatkar, and Moberg as the combination does not teach all of the features of the claim. 
Dependent claims 9-15 and 17 are likewise allowable. 

Further regarding claim 10, the claim recites "determining if the packet is a mal- 
formed packet." The Office Action proposes that this feature is taught in Moberg, similar to 
claim 1 discussed above. As discussed above with respect to claim 1, Moberg does not teach 
this feature. For at least this additional reason, claim 10 is allowable over the combination of 
Shenoy, Yavatkar, and Moberg and allowance is respectfully requested. 

Further regarding claim 1 1, the claim recites "applying a packet filter to the packets." 
The Office Action proposes that this feature is taught in Moberg because it teaches that after 
validation, a packet is processed {see Office Action, page 1 1). The applicant respectfully 
disagrees. Although Moberg does teach that a packet is processed at the line card, it does not 
teach that a packet filter is applied to the packet. For at least this additional reason, claim 1 1 
is allowable over the combination of Shenoy, Yavatkar, and Moberg and allowance is 
respectfully requested. 

Further regarding claim 12, the claim recites "applying an address filter to the 
packets." The Office Action proposes that this feature is taught in Moberg because it teaches 
that a line card examines the address of a packet (see Office Action, page 12). The applicant 
respectfully disagrees. Although Moberg does teach that a line card examines the address of 
a packet, it does not teach that an address filter is applied to the packet. Specifically, Moberg 
merely teaches that the line card examines the address to determine which card should 
process the packet {see Moberg, col. 4, lines 49-53). Therefore, Moberg does not teach 
applying an address filter to a packet. For at least this additional reason, claim 12 is 
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allowable over the combination of Shenoy, Yavatkar, and Moberg and allowance is 
respectfully requested. 

Further regarding claim 13, the claim recites "transmitting data related to valid 
updates from the peer gateways." The Office Action proposes that this feature is taught in 
Shenoy at paragraph [0027] {see Office Action, page 5). The applicant respectfully 
disagrees. The cited portion of Shenoy simply teaches that a line card can communicate with 
a control card; it does not describe the substance of such communication. At paragraph 
[0033] Shenoy provides more detail on what information is exchanged between the line card 
and control card, but it does not mention any valid updates from peer gateways (all of the 
described communications take place between operating systems in the same router). 
Consequently, Shenoy does not teach this feature of the claim. For at least this additional 
reason, claim 13 is allowable over the combination of Shenoy, Yavatkar, and Moberg and 
allowance is respectfully requested. 

Regarding claim 25, the claim recites "configuring the line cards." The Office Action 
proposes that this feature is taught in Shenoy by the phrase "receiving traffic into the network 
node" at paragraph [0020] {see Office Action, page 6). The applicant respectfully disagrees. 
The cited portion of Shenoy actually refers to the fimctionality provided by the line cards; it 
does not make any mention of the line cards being configured. The remaining disclosure of 
Shenoy does not remedy this deficiency. Consequently, the combination of Shenoy, 
Yavatkar, and Moberg does not teach this feature of the claim. 

Claim 25 also recites "providing a routing table and policy data to each line card." 
The Office Action proposes that this feature is taught in Shenoy by the phrase "the line card 
processors 118 are configured for routing information etc" at paragraph [0022] {see Office 
Action, page 6). The applicant respectfully disagrees. The cited portion of Shenoy actually 
refers to how forwardmg information is managed between the line and control cards. The 
applicant does not find the quoted language anywhere in this portion of Shenoy or any other 
language referring to providing policy data to a line card. Consequently, the combination of 
Shenoy, Yavatkar, and Moberg does not teach this feature of the claim. 

Claim 25 further recites "registering a control portion of a protocol to be executed by 
the control card with a central registration point." The Office Action proposes that this 
feature is taught in Yavatkar at FIG. 3 and the accompanying description {see Office Action, 
page 10). The applicant respectfully disagrees. FIG. 3 and the accompanying description of 
Yavatkar actually describes how routers can exchange messages without having packets 
forwarded to the respective control planes {see Yavatkar, paragraph [0021]). Yavatkar does 
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not teach that any control portions are registered with a central registration point. Neither of 
the routers in FIG. 3 of Yavatkar is a central registration point because they are both identical 
routers running the distributed control protocol. Therefore, Yavatkar does not teach this 
feature of the claims. Consequently, the combination of Shenoy, Yavatkar, and Moberg does 
not teach this feature of the claim. 

For at least the reasons identified above, claim 25 is allowable over the combination 
of Shenoy, Yavatkar, and Moberg as the combination does not teach all of the features of the 
claim. Dependent claims 27-29 are likewise allowable. 

Further regarding claim 27, the claim recites "registering the control portion with a 
distributed control plane architecture infrastructure module." The Office Action proposes 
that Shenoy teaches this feature because it teaches a distribution engme that manages the 
distribution of forwarding information {see Office Action, page 6). The applicant 
respectfully disagrees. As the Office Action acknowledges, the distribution engine of Shenoy 
manages distribution of forwarding information {see also Shenoy, paragraph [0033]); not 
registration of the control portion of a protocol. Shenoy does not teach any other elements 
registering the control portion of a protocol. Therefore, Shenoy does not teach this feature of 
the claim. For at least this additional reason, claim 27 is allowable over the combination of 
Shenoy, Yavatkar, and Moberg and allowance is respectfully requested. 

Regarding claims 30-34, the claims recite features similar to those discussed above 
with respect to claim 8 and its dependent claims. Consequently, claims 30-34 are allowable 
over the combination of Shenoy, Yavatkar, and Moberg for at least the same reasons 
discussed above with respect to claim 8. 

Claims 18-19, 21 and 24 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Shenoy, et al. (U.S. Publication No. 2003/0223425 Al) in view of 
Yavatkar, et al. (U.S. Publication No. 2003/0128668 Al) and Moberg, et al. (U.S. Patent No. 
6,697,872 B2) as applied to claim 18 above, and further in view of Macera, et al. (U.S. Patent 
No. 5,490,252). The applicant traverses the rejections. 

Regarding claim 18, the claim recites "transmit data resource data to the control 
card." The Office Action proposes that this feature is taught in Shenoy because it teaches 
"forwarding information to control module" {see Office Action, page 14). The applicant 
respectfully disagrees. Shenoy specifically teaches that forwarding information is exchanged 
between the line cards and the control card. Shenoy does not teach that data resource data is 
sent to the control card. Therefore, Shenoy does not teach this feature of the claim. 
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Claim 18 also recites "receiving configuration information from the control card." 
The Office Action proposes that this feature is taught in Shenoy because the line card 
receives traffic into the network node (see Office Action, page 14). The applicant 
respectfully disagrees. Specifically, the fact that the line cards in Shenoy receive traffic does 
not necessarily mean that the line cards receive configuration mformation from a control 
card. As an example, the line cards could maintain their own configuration information 
without receiving any configuration information from the control card. Shenoy does not 
explicitly teach that the line cards receive configuration information from the control card 
and the applicant does not find any suggestion of such in Shenoy. Therefore, Shenoy does 
not teach this feature of the claim. 

Claim 18 further recites "establishing connections with exterior gateway peers." The 
Office Action proposes that this feature is taught in Shenoy because it teaches that the line 
cards have ports to terminate links (see Office Action, page 14). The applicant respectfully 
disagrees. Specifically, the fact that the line cards in Shenoy have ports does not necessarily 
mean that the line cards establish connections with exterior gateway peers. Shenoy does not 
make any mention of exterior gateway peers, or more specifically, establishing connections 
with exterior gateway peers. Therefore, Shenoy does not teach this feature of the claim. 

Also, claim 18 recites "transmitting only valid Border Gateway Protocol data to the 
control card." The Office Action proposes that this feature is taught in Shenoy because it 
teaches that the line cards communicate with the control module {see Office Action, page 14). 
The applicant respectfully disagrees. Specifically, the fact that the line cards in Shenoy 
communicate with the control module does not necessarily mean that the line cards transmit 
only valid BGP data to the confrol module. To the contrary, Shenoy actually teaches that the 
line cards can transmit many types of data to the control module (see Shenoy, paragraph 
[0017]). Further, Shenoy does not teach that the line cards distinguish between valid and 
invalid data packets in determining which data packets to forward to the control module. 
Therefore, Shenoy does not teach this feature of the claim. 

Further, claim 18 recites "registering an offload portion of a protocol to be executed 
by the line card with a central registration point." As discussed above, with respect to claim 
25, Yavatkar does not teach this feature as the Office Action proposes. The same arguments 
presented above with respect to claim 25 apply here. 

Claim 18 also recites "running output policies for each of the gateway peers." The 
Office Action proposes that Moberg teaches this feature because it teaches that a line card 
verifies the validity of a packet (see Office Action, page 15). The applicant respectfully 
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disagrees. The verification process pointed to in the Office Action refers to a line card 
processing packets received locally; it does not refer to running output policies for gateway 
peers. There is no mention anywhere else in Moberg of a line card running output policies 
for gateway peers. Consequently, this feature of the claim is not taught in Moberg. 

Claim 18 further recites "initializing a line card." The Office Action proposes that 
this feature is taught in Macera because it teaches that "each module is automatically self- 
configured when inserted into the backplane" (see Office Action, page 15). The applicant 
respectfully disagrees. Macera specifically teaches that a BES includes multiple modules that 
can be 'hot swapped' (see Macera, col. 7, lines 25-29). However, Macera does not teach that 
any of these components are a line card. Macera does not actually give any details of what 
these modules might be; only that they can be swapped out. Consequently, Macera does not 
teach this feature of claim 18. 

Finally, claim 18 recites "performing Border Gateway Protocol functions at the line 
card." The Office Action proposes that Macera teaches this feature because its BES supports 
BGP (see Office Action, page 15). The applicant respectfully disagrees. Specifically, there 
is nothing in Macera to indicate that its BES is a line card or includes a line card. Therefore, 
the fact that Macera's BES supports BGP does not teach performing BGP functions at a line 
card, as recited in the claim. Consequently, Macera does not teach this feature of claim 18. 

For each of the reasons identified above, claim 18 is allowable over the combination 
of Shenoy, Yavatkar, Moberg, and Macera as the combination does not teach all of the 
features of the claim. Therefore, allowance of claim 1 8 and its dependent claims, 19-22 and 
24, is respectfully requested. 

Further regarding claim 19, the claim recites "registering with a distributed control 
plane architecture infrastructure module." As discussed above with respect to claim 27, the 
combination of Shenoy, Yavatkar, and Moberg does not teach this feature. Macera does not 
make up for this deficiency. For at least this additional reason, claim 19 is allowable over the 
combination of Shenoy, Yavatkar, Moberg, and Macera and allowance is respectfully 
requested. 

Further regarding claim 21, the claim recites "filtering mal-formed, illegal and 
duplicate update messages from the gateway peers." As discussed above with respect to 
claim 1, these features are not taught in the combination of Shenoy, Yavatkar, and Moberg. 
Macera does not make up for this deficiency. For at least this additional reason, claim 21 is 
allowable over the combination of Shenoy, Yavatkar, Moberg, and Macera and allowance is 
respectfully requested. 
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Claim 15 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Shenoy, et al. (U.S. Publication No. 2003/0223425 Al) in view of Yavatkar, et al. (U.S. 
Publication No. 2003/0128668 Al) and Moberg, et al. (U.S. Patent No. 6,697,872 B2) as 
applied to claim 8 above, and further in view of Harvey, et al. (U.S. Publication No. 
2003/0140167 Al). The applicant traverses the rejection. 

Claim 15 depends from claim 8 and thus contains all of the features of claim 8. 
Consequently, claim 15 is allowable over the combination of Shenoy, Yavatkar, Moberg, and 
Harvey at least because any claim that depends from a nonobvious independent claim is also 
nonobvious. 

Claim 15 recites "generating responses required by the incoming packets." The 
Office Action acknowledges that this feature is not taught in Shenoy, Yavatkar, and Moberg, 
but then proposes that this feature is taught in Harvey at paragraph [0030] (see Office Action, 
page 17). The applicant respectfiiUy disagrees. The cited portion of Harvey merely teaches 
that an acknowledgement message can be sent every time a packet is received at a routing 
module. Harvey does not teach that such an acknowledgment message was required by the 
incoming packet. Harvey appears to teach that its system does not distinguish between 
incoming packets requiring an acknowledgement and those that do not. Instead, in Harvey, 
all incoming packets generate an acknowledgment message. Therefore, Harvey does not 
teach this feature of the claim. For at least this additional reason, claim 15 is allowable over 
the combination of Shenoy, Yavatkar, Moberg, and Harvey. 

Reconsideration and allowance of all claims is requested. The Examiner is 
encouraged to telephone the undersigned at (503) 222-3613 if it appears that an interview 
would be helpfiil in advancing the case. 
Customer No. 32231 



RespectfiiUy submitted. 
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